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1 REAL PARTY IN INTEREST 

The real party in interest is Hewlett-Packard Development Company, LP., the 
Assignee of the above-referenced application by virtue of the Assignment recorded at reel 
015260, frame 0741, and dated April 26, 2004. Accordingly, Hewlett-Packard 
Development Company, L.P. will be directly affected by the Board's decision in the 
pending appeal. 

2 RELATED APPEALS AND INTERFERENCES 

Appellants are unaware of any other appeals or interferences related to this 
Appeal. The undersigned is Appellants' legal representative in this Appeal. 

3 STATUS OF CLAIMS 

Claims 1-26 are currently pending, are currently under final rejection and, thus, 
are the subject of this Appeal. 

4 STATUS OF AMENDMENTS 

There are no outstanding amendments to be considered by the Board. 

5 SUMMARY OF CLAIMED SUBJECT MATTER 

The Application contains four independent claims, namely, claims 1, 11,21, and 
26, all of which are the subject of this Appeal. The subject matter of these claims is 
summarized below. 
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Claims 1, 11,21, and 26 relate to devices and techniques involved in managing of 
a data transfer between networked computer systems. See Application, page 1 1, line 19 - 
page 12, line 1. The networked computer systems may include processor nodes that may 
exchange information and share memories across the computer systems. See id., page 8, 
lines 1-2. Moreover, this exchange of information and memory sharing may be 
accomplished through the use of protocol stacks. See id., page 8, lines 4-6. The protocol 
stack may include a plurality of protocols utilized by a process or application to perform 
certain functions during the data transfer. See id., page 8, lines 9-11; page 12, lines 1-7; 
page 14, lines 3-6. By utilizing protocol stacks, the communication between computer 
systems may be maintained and may also be more efficient. See id, page 18, lines 6-7. 

With regard to the aspect of the invention set forth in independent claim 1, 
discussions of the recited features of claim 1 can be found at least in the below cited 
locations of the specification and drawings. Claim 1 generally relates to an apparatus for 
managing flow control of a data transfer. By way of example, present embodiments 
include a processor (e.g., 102, 104, 302; Application, page 6, lines 13-14) adapted to 
operate (e.g., Application, page 8, lines 4-6) according to a first protocol (e.g., 306) 
associated with a plurality of receive buffers. See Application, page 13, lines 14-15, and 
page 13, line 17 - page 14, line 1. Further, present embodiments include the processor 
(e.g., 102, 104, 302; Application, page 6, lines 13-14) being further adapted to operate 
according to a second protocol (e.g., 310) adapted to manage the plurality of receive 
buffers for the first protocol (e.g., Application, page 14, lines 4-6), the processor (e.g., 
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102, 104, 302; Application, page 6, lines 13-14) being further adapted to operate 
according to a third protocol (e.g., 314) that determines whether one of the plurality of 
receive buffers is available for a data packet (e.g., 314, 330; Application, page 17, lines 
10-12) and, if one of the plurality of receive buffers is available, permits an 
acknowledgement packet to be sent to a node that sent the data packet (e.g., Application, 
page 17, lines 15-17), and, if one of the plurality of receive buffers is unavailable, drops 
the data packet, notifies the second protocol regarding the unavailability of the plurality 
of receive buffers, and withholds the acknowledgement packet. See Application, page 
17, line 17 -page 18, line 2. 

With regard to the aspect of the invention set forth in independent claim 1 1, 
discussions of the recited features of claim 1 1 can be found at least in the below cited 
locations of the specification and drawings. By way of example, present embodiments 
include a plurality of systems (e.g., 102, 1 10, 302, 304), at least one of the plurality of 
systems executing a process (e.g., 306), and at least one input/output device (e.g., 126) 
adapted to receive a data packet from the at least one of the plurality of systems (e.g., 
Application, page 8, lines 1-6), the at least one input/output device comprising: a first 
protocol (e.g., 306) associated with a plurality of receive buffers. See Application, page 
13, lines 14-15, and page 13, line 17 - page 14, line 1. Further, present embodiments 
include a second protocol (e.g., 310) adapted to manage the plurality of receive buffers 
for the first protocol (e.g., Application, page 14, lines 4-6) and a third protocol (e.g., 314) 
that determines whether one of the plurality of receive buffers is available for a data 
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packet (e.g., 314, 330; Application, page 17, lines 10-12) and, if one of the plurality of 
receive buffers is available, permits an acknowledgement packet to be sent to a node that 
sent the data packet (e.g., Application, page 17, lines 15-17), and, if one of the plurality 
of receive buffers is unavailable, drops the data packet, notifies the second protocol 
regarding the unavailability of the plurality of receive buffers, and withholds the 
acknowledgement packet. See Application, page 17, line 17 - page 18, line 2. 

With regard to the aspect of the invention set forth in independent claim 21, 
discussions of the recited features of claim 21 can be found at least in the below cited 
locations of the specification and drawings. By way of example, present embodiments 
include the acts of receiving a data packet (e.g., 404), determining whether at least one 
receive buffer is available for the data packet (e.g., 404), if the at least one buffer is 
available, sending an acknowledgement packet to a node that sent the data packet (e.g., 
Application, page 19, lines 10-12), and if the at least one buffer is unavailable (e.g., 
Application, page 19, lines 17-18), dropping the data packet (e.g., 416), providing a 
notification regarding the unavailability of the at least one buffer (e.g., Application, page 
19, lines 18-19), and withholding an acknowledgement packet from the node that sent the 
data packet (e.g., 418; Application, page 20, lines 3-4). 

With regard to the aspect of the invention set forth in independent claim 26, 
discussions of the recited features of claim 26 can be found at least in the below cited 
locations of the specification and drawings. By way of example, present embodiments 
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include means for receiving a data packet at a first protocol (e.g., 304; Application, page 
18, lines 16-17), means for determining whether at least one receive buffer is available 
for the data packet (e.g., 334; Application, page 19, lines 1-4), means for sending an 
acknowledgement packet to a node that send the data packet if the at least one buffer is 
available (e.g., 334; Application, page 19, lines 7-12), and means for dropping the data 
packet (e.g., 332; Application, page 20, lines 1-3), notifying a second protocol regarding 
the unavailability of the at least one buffer (e.g., Application, page 19, line 17 - page 20, 
line 1), and preventing an acknowledgement packet from being sent if the at least one 
buffer is unavailable (e.g., 418; Application, page 20, lines 3-4). 

6 GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

First Ground of Rejection for Review on Appeal : 

Appellants respectfully urge the Board to review and reverse the Examiner's first 
ground of rejection in which the Examiner rejected claims 1-26 under 35 U.S.C. § 1 12, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which Appellants regard as the invention. 

Second Ground of Rejection for Review on Appeal ; 

Appellants respectfully urge the Board to review and reverse the Examiner's 
second ground of rejection in which the Examiner rejected claims 1, 2, 4, 7-12, 14, 17-23, 
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25, and 26 under 35 U.S.C. § 102(b) as being taught by Recio et al, International Patent 
number WO 00/72142 (hereinafter referred to as "the Recio reference"). 



7 ARGUMENT 

As discussed in detail below, the Examiner has improperly rejected the pending 
claims. Further, the Examiner has misapplied long-standing and binding legal precedents 
and principles in rejecting the claims under Sections 1 12 and 102. Accordingly, 
Appellants respectfully request full and favorable consideration by the Board, as 
Appellants strongly believe that claims 1-26 are currently in condition for allowance. 



A. Ground of Rejection No. 1: 

With respect to the Examiner's rejection of claims 1-26 under 35 U.S.C. § 1 12, 

second paragraph, the Examiner stated the following: 

Throughout the text of the claims the applicant utilizes 
the term protocol, in some areas the conventional 
meaning of a protocol seems to apply (i.e. transmitted 
by an upper layer protocol) ', however the applicant 
fails to explicate what is meant by it in other areas (i.e. 
DDP protocol iWARP protocol). The examiner will 
interpret the term protocol to mean a way to transmit 
data between any two devices. 

Office Action, page 2. 

Appellants respectfully traverse the rejection. The Examiner's focus during 
examination of claims for compliance with the requirement for definiteness under 35 
U.S.C. § 112, second paragraph, should be whether the claim meets the threshold 
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requirements of clarity and precision, not whether more suitable language or modes of 
expression are available. See M.P.E.P. § 2173.02. Appellants may use functional 
language, alternative expressions, negative limitations, or any style of expression or 
format of claim which makes clear the boundaries of the subject matter for which 
protection is sought. See M.P.E.P. §§ 2173.01 and 2173.05; In re Swinehart, 160 
U.S.P.Q. 226 (C.C.P.A. 1971). The Examiner is also reminded not to equate breadth of a 
claim with indefiniteness. In re Miller, 169 U.S.P.Q 597 (C.C.P.A. 1971). 

The essential inquiry pertaining to the definiteness requirement is whether the 
claims set out and circumscribe a particular subject matter with a reasonable degree of 
clarity and particularity. See M.P.E.P. § 2173.02. As set forth in Section 2173 of the 
Manual of Patent Examining Procedure, definiteness of claim language must be analyzed, 
not in a vacuum, but in light of: 

(A) The content of the particular application disclosure; 

(B) The teachings of the prior art; and 

(C) The claim interpretation that would be given by one possessing the ordinary 
level of skill in the pertinent art at the time the invention was made. 

In reviewing a claim for compliance with 35 U.S. C. § 1 12, second paragraph, the 
Examiner must consider the claim as a whole to determine whether the claim apprises 
one of ordinary skill in the art of its scope and, therefore, serves the notice function 
required by 35 U.S. C. § 112, second paragraph, by providing clear warning to others as to 
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what constitutes infringement of the patent. See Solomon v. Kimberly-Clark Corp., 55 
U.S.P.Q.2d 1279, 1283 (Fed. Cir. 2000). Only when a claim remains insolubly 
ambiguous without a discernible meaning after all reasonable attempts at construction 
must it be declared indefinite. See Metabolite Labs., Inc. v. Lab. Corp. of Am. Holdings, 
71 U.S.P.Q.2d 1081, 1089 (Fed. Cir. 2004). Accordingly, a claim term that is not used or 
defined in the specification is not indefinite if the meaning of the claim term is 
discernible. See Bancorp Services, L.L.C v. Hartford Life Ins. Co., 69 U.S.P.Q.2d 1996, 
1999-2000 (Fed. Cir. 2004). 

Appellants submit that the term "protocol," as recited in claims 1-7, 9-17, 19, 20, 
23, 24, and 26, is not indefinite because the meaning of the claim term is discernable and 
is clearly supported by the specification (e.g., Application, page 2, lines 12-15, page 8 
lines 8-11). The specification clearly allows for a process protocol 202 to comprise, for 
example, a process, an upper layer protocol, or an application that may interact with the 
protocol stack to communicate with other devices or within the node, as well as with an 
application protocol. See Application, page 8, lines 12-14 and 18-19. Similarly, an 
application protocol (e.g., 204) is clearly described by the specification as being an 
Internet small computer systems interface that interacts with a protocol or a group of 
protocols, collectively referred to as a datamover protocol layer (e.g. 206). See 
Application, page 8, line 18 - page 9, line 2. Further protocols, such as an iWARP 
protocol are also clearly described by the specification. See Application, page 9, lines 4- 
11. 
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Indeed, although the term protocol is used throughout the specification, each 
protocol is clearly defined, which distinguishes between the types of protocols disclosed. 
These separate protocols are also claimed. 

For example, claim 1 recites a first, a second, and a third protocol, each associated 
with recited claim elements and/or actions. Each of these first, second, and third 
protocols are supported in the specification. For example, the first protocol may be an 
upper layer protocol such as an Internet small computer systems interface protocol, while 
the second protocol may be a datamover protocol, and the third protocol may be an 
iWAEP protocol. Moreover, the protocols recited in claim one are clearly modified by 
numeric adjectives (first protocol, second protocol, and third protocol) at least to avoid 
confusion to one skilled in the art, and the protocols, as shown above, are clearly 
supported in the specification both by category and by the type of actions that the 
protocols undertake, as well as the interaction between corresponding protocols. Because 
the term "protocol" is clearly defined in the specification, and the claimed "protocols" are 
distinguishable in the claims, the Section 1 12 rejection of claims 1-26 is improper. 

Thus, the Examiner in incorrect in asserting some areas of the claims include the 
term "protocol" with an apparently conventional meaning, while other areas reference 
non-explicated meanings. Both the specification, and the claims, clearly delineate 
between the different types of protocols claimed. Accordingly, for at least the reasons set 
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forth above, Appellants respectfully request the Board reverse the Examiner's rejection 
under 35 U.S.C. § 1 12, second paragraph, of independent claims 1, 1 1, 21, and 26, as 
well as all claims depending therefrom. 



B» Ground of Rejection No, 2: 

The Examiner rejected claims 1, 2, 4, 7-12, 14, 17-23, 25, and 26 under 35 U.S.C. 
§ 102(b) as being taught by the Recio reference. Specifically, with regard to independent 
claims 1,11,21, and 26, the Examiner stated in relevant part: 



Claim 1: 

An apparatus for managing flow control of a data transfer, 
comprising: a first protocol associated with a plurality of receive 
buffers (Figures 1-5 and Page 8 lines 4-11; multiple storage and 
memory components); a second protocol adapted to manage the 
plurality of receive buffers for the first protocol (Figure 1-5 and 
Page 5 lines 5-12; processors); and a third protocol that determines 
whether one of the plurality of receive buffers is available for a 
data packet and (a) if one of the plurality of receive buffers is 
available, permits an acknowledgement packet to be sent to a node 
that sent the data packet, and (b) if one of the plurality of receive 
buffers is unavailable, drops the data packet, notifies the second 
protocol regarding the unavailability of the plurality of receive 
buffers, and withholds the acknowledgement packet (Figures 1-5 
Page 12 line 25- Page 13 line 5 & Page 14 lines 3-7 & Page 23 
lines 29-31; reliability, acknowledgment, successive retries and 
time-outs). 

Claim 1 1 : 

A network, comprising: a plurality of systems, at least one of the 
plurality of systems executing a process; and at least one 
input/output device adapted to receive a data packet from the at 
least one of the plurality of systems (Figures 1-5 and Page 4 lines 
21-28: multiple systems/processors, WANs and LANs), the at least 
one input/output device comprising: a first protocol associated with 
a plurality of receive buffers (Figures 1-5 and Page 8 lines 4-11; 
multiple storage and memory components); a second protocol 
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adapted to manage the plurality of receive buffers for the first 
protocol (Figure 1-5 and Page 5 lines 5- 12; processors); and a 
third protocol that determines whether one of the plurality of 
receive buffers is available for a data packet and (a) if one of the 
plurality of receive buffers is available, permits an 
acknowledgement packet to be sent to a node that sent the data 
packet, and (b) if one of the plurality of receive buffers is 
unavailable, drops the data packet, notifies the second protocol 
regarding the unavailability of the plurality of receive buffers, and 
withholds the acknowledgement packet (Figures 1-5 Page 12 line 
25- Page 13 line 5 & Page 14 lines 3-7 & Page 23 lines 29-31; 
reliability, acknowledgment, successive retries and time-outs). 

Claim 21: 

A method of managing flow control of a data transfer, the method 
comprising the acts of: receiving a data packet; determining 
whether at least one receive buffer is available for the data packet 
(Figures 2-5 & 9B & 11 and Page 38 lines 17-26: end-node's 
availability); if the at least one buffer is available, sending an 
acknowledgement packet to a node that sent the data packet 
(Figures 1-5 Page 13 line 25- Page 13 line 5 & Page 14 lines 3-7 & 
Page 23 lines 29-31; reliability, acknowledgment, successive 
retries and timeouts); and if the at least one buffer is unavailable, 
dropping the data packet, providing a notification regarding the 
unavailability of the at least one buffer, and withholding an 
acknowledgement packet from the node that sent the data packet 
(Figures 1-5 Page 12 line 25- Page 13 line 5 & Page 14 lines 3-7 & 
Page 23 lines 29-31: reliability, acknowledgment, successive 
retries and time-outs). 

Claim 26: 

An apparatus for managing flow control of a data transfer, 
comprising: means for receiving a data packet at a first protocol 
(Page 9 lines 29-31 & Page 10 lines 1-2 & 26-31 & Page 11 lines 
1-2; reads off of the limitation of a single or multiple receive 
buffers); means for determining whether at least one receive buffer 
is available for the data packet (Figures 1-5 and Page 8 lines 4-11; 
multiple storage and memory components); means for sending an 
acknowledgement packet to a node that send the data packet if the 
at least one buffer is available (Figures 1-5 Page 12 line 25- Page 
13 line 5 & Page 14 lines 3-7 & Page 23 lines 29-31; reliability, 
acknowledgment, successive retries and time-outs); and means for 
dropping the data packet, notifying a second protocol regarding the 
unavailability of the at least one buffer, and preventing an 
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acknowledgement packet from being sent if the at least one buffer 
is unavailable (Figures 1-5 Page 12 line 75- Page 13 line 5 & Page 
13 lines 3-7 & Page 23 lines 29-31: reliability, acknowledgment, 
successive retries and time-outs). 

Appellants respectfully traverse this rejection. Anticipation under Section 102 
can be found only if a single reference shows exactly what is claimed. Titanium Metals 
Corp. v. Banner, 778 F.2d 775, 227 U.S.P.Q. 773 (Fed. Cir. 1985). For a prior art 
reference to anticipate under Section 102, every element of the claimed invention must be 
identically shown in a single reference. In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 
(Fed. Cir. 1990). To maintain a proper rejection under Section 102, a single reference 
must teach each and every limitation of the rejected claim. Atlas Powder v. E.I. du Pont, 
750 F.2d 1569 (Fed. Cir. 1984). The prior art reference also must show the identical 
invention "in as complete detail as contained in the ... claim" to support a prima facie 
case of anticipation. Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236, 9 U.S.P.Q. 
2d 1913, 1920 (Fed. Cir. 1989) (emphasis added). Accordingly, Appellants need only 
point to a single element not found in the cited reference to demonstrate that the cited 
reference fails to anticipate the claimed subject matter. 

Claim Features of Independent Claims 7, 77, 21, and 26 Omitted from the Redo 
Reference 

The Examiner rejected claims 1, 2, 4, 7-12, 14, 17-23, 25, and 26 under 35 U.S.C. 
§ 102(b) as being taught by the Recio reference. With respect to the Examiner's rejection 
of claims 1, 2, 4, 7-12, 14, 17-23, 25, and 26 under 35 U.S.C. § 102(b), the Examiner's 
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rejections with respect to independent claims 1, 11,21, and 26 are exemplary. 
Independent claims 1, 11,21, and 26 will be argued as a group, whereby the similar claim 
language found in each of claims 1, 11,21, and 26 may represent allowable subject 
matter for each of claims 1, 11,21, and 26. 

The Recio reference fails to anticipate all elements of independent claims 1,11, 
21, and 26. Independent claim 1 recites, inter alia, "the processor being further adapted 
to operate according to a second protocol adapted to manage the plurality of receive 
buffers for the first protocol, the processor being further adapted to operate according to a 
third protocol that determines whether one of the plurality of receive buffers is available 
for a data packet and (a) if one of the plurality of receive buffers is available, permits an 
acknowledgement packet to be sent to a node that sent the data packet, and (b) if one of 
the plurality of receive buffers is unavailable, drops the data packet, notifies the second 
protocol regarding the unavailability of the plurality of receive buffers, and withholds the 
acknowledgement packet." (Emphasis added). Similarly, Independent claim 1 1 recites, 
inter alia, "a second protocol adapted to manage the plurality of receive buffers for the 
first protocol; and a third protocol that determines whether one of the plurality of receive 
buffers is available for a data packet and (a) if one of the plurality of receive buffers is 
available, permits an acknowledgement packet to be sent to a node that sent the data 
packet, and (b) if one of the plurality of receive buffers is unavailable, drops the data 
packet, notifies the second protocol regarding the unavailability of the plurality of receive 
buffers, and withholds the acknowledgement packet." (Emphasis added). 
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Likewise, independent claim 21 recites, inter alia, "receiving a data packet; 
determining whether at least one receive buffer is available for the data packet; if the at 
least one buffer is available, sending an acknowledgement packet to a node that sent the 
data packet; and if the at least one buffer is unavailable, dropping the data packet, 
providing a notification regarding the unavailability of the at least one buffer, and 
withholding an acknowledgement packet from the node that sent the data packet " 
(Emphasis added). Similarly, independent claim 26 recites, inter alia, "means for 
determining whether at least one receive buffer is available for the data packet; means for 
sending an acknowledgement packet to a node that send the data packet if the at least one 
buffer is available; and means for dropping the data packet, notifying a second protocol 
regarding the unavailability of the at least one buffer, and preventing an 
acknowledgement packet from being sent if the at least one buffer is unavailable." 
(Emphasis added). 

First, the cited sections of the Recio reference, as well as the remainder of the 
reference, fail to describe a processor being further adapted to operate according to a 
third protocol that determines whether one of the plurality of receive buffers is available 
for a data packet. The Recio reference does describe a data transfer system using queue 
pairs and corresponding work queue elements for the transfer of data. See Recio, page 8, 
line 29 - page 9, line 9. Moreover, the Recio reference describes a work queue as 
containing a work queue element that describes where to place incoming data. See Recio, 
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page 9, lines 10-11. However, a component that merely describes where data is intended 
to be placed is not analogous to determining whether one of the plurality of receive 
buffers is available for placing a data packet. As such, the Recio reference fails to 
describe a processor being further adapted to operate according to a third protocol that 
determines whether one of the plurality of receive buffers is available for a data packet, 
as recited in independent claims 1, 11, 21, and 26. 

Second, the cited sections of the Recio reference, as well as the remainder of the 
reference, fail to describe permitting an acknowledgement packet to be sent if one of the 
plurality of receive buffers is available. The Recio reference clearly discloses 
transmitting acknowledgement packets for all frame (data) transfers. See Recio, page 12, 
lines 25-3 1. Indeed, the Recio reference specifically states that "the acknowledgment 
does not validate that the receiving process has consumed the data," but rather that "the 
data has reached its destination." Id. at page 13, lines 2-5, page 13, lines 1-5, and page 
22, lines 15-19. Thus the Recio reference describes transmitting acknowledgement when 
packets are received regardless of the availability of locations for the receiving process to 
store the packets. As such, the Recio reference fails to describe permitting an 
acknowledgement packet to be sent, or sending an acknowledgement packet, if one of the 
plurality of receive buffers is available, as recited in independent claims 1, 11,21, and 
26. 
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Third, the cited sections of the Recio reference, as well as the remainder of the 
reference, fail to describe notifying the second protocol regarding the unavailability of the 
plurality of receive buffers if one of the plurality of receive buffers is unavailable. The 
Recio reference discloses, at best, retransmitting frames to a destination when an 
acknowledgement is not received by the source. See Recio, page 23, lines 29-3 1. Even 
if, arguendo, the lack of transmission of an acknowledgment were due to a receive buffer 
being unavailable, there is no discussion in the Recio reference of notifying a second 
protocol of the unavailability of a receive buffer. Indeed, the lack of an 
acknowledgement indicates only that a packet was not received, it does not indicate to 
any protocol why the packet was not received, i.e. because of the unavailability of a 
receive buffer. Lack of transmission of an acknowledgment is not analogous to both 
actively notifying the second protocol regarding the unavailability of the plurality of 
receive buffers, as well as withholding the acknowledgement packet. As such, the Recio 
reference fails to describe if one of the plurality of receive buffers is unavailable, 
dropping the data packet, notifying the second protocol regarding the unavailability of the 
plurality of receive buffers, and withholding the acknowledgement packet, as recited in 
independent claims 1, 11, 21, and 26. 

For at least these reasons, Appellants respectfully submit that independent claims 
1, 11,21, and 26, as well as all claims depending therefrom, are not anticipated by the 
Recio reference. Accordingly, Appellants respectfully request the withdrawal of the 
rejection of independent claims 1, 11,21, and 26 under Section 102 based on the Recio 
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reference, and further request allowance independent claims 1, 11,21, and 26, as well as 
all claims depending therefrom. 

Conclusion 

Appellants respectfully submit that all pending claims are in condition for 
allowance. However, if the Examiner or Board wishes to resolve any other issues by way 
of a telephone conference, the Examiner or Board is kindly invited to contact the 
undersigned attorney at the telephone number indicated below. 



CORRESPONDENCE ADDRESS: 
HEWLETT-PACKARD COMPANY 

Intellectual Property Administration 
P.O. Box 272400 

Fort Collins, Colorado 80527-2400 



Respectfully submitted, 



Date: April 29. 2008 




Michael G. Fletcher 
Reg. No. 32,777 
FLETCHER YODER 
P.O. Box 692289 
Houston, TX 77269-2289 
(281)970-4545 
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8 APPENDIX OF CLAIMS ON APPEAL 
Listing of Claims: 

1 . An apparatus for managing flow control of a data transfer, comprising: 
processor adapted to operate according to a first protocol associated with a plurality of 
receive buffers, the processor being further adapted to operate according to a second 
protocol adapted to manage the plurality of receive buffers for the first protocol, the 
processor being further adapted to operate according to a third protocol that determines 
whether one of the plurality of receive buffers is available for a data packet and (a) if one 
of the plurality of receive buffers is available, permits an acknowledgement packet to be 
sent to a node that sent the data packet, and (b) if one of the plurality of receive buffers is 
unavailable, drops the data packet, notifies the second protocol regarding the 
unavailability of the plurality of receive buffers, and withholds the acknowledgement 
packet. 

2. The apparatus set forth in claim 1, wherein the first protocol is an upper 
layer protocol ("ULP"). 

3. The apparatus set forth in claim 2, wherein the upper layer protocol is an 
internet small computer systems interface ("iSCSI") protocol. 

4. The apparatus set forth in claim 1, wherein the second protocol is a 
datamover protocol. 
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5. The apparatus set forth in claim 1, wherein the third protocol is an iWARP 
protocol. 

6. The apparatus set forth in claim 5, wherein the iWARP protocol is a direct 
data placement ("DDP") protocol. 

7. The apparatus set forth in claim 1, comprising a transport protocol that 
generates a request to the third protocol to determine whether one of the plurality of 
receive buffers is available for the data packet. 

8. The apparatus set forth in claim 1, wherein the data packet comprises a 
sequence field that corresponds to a reliability tracking value for the data packet. 

9. The apparatus set forth in claim 1, wherein the acknowledgement packet 
comprises an acknowledgement field that corresponds to an identity of data received by 
the transport protocol. 

10. The apparatus set forth in claim 1, comprising a transport protocol that 
uses a remote direct memory access network interface card ("RNIC") to receive the data 
packet and send the acknowledgement packet. 
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11. A network, comprising: a plurality of systems, at least one of the plurality 
of systems executing a process; and at least one input/output device adapted to receive a 
data packet from the at least one of the plurality of systems, the at least one input/output 
device comprising: a first protocol associated with a plurality of receive buffers; a second 
protocol adapted to manage the plurality of receive buffers for the first protocol; and a 
third protocol that determines whether one of the plurality of receive buffers is available 
for a data packet and (a) if one of the plurality of receive buffers is available, permits an 
acknowledgement packet to be sent to a node that sent the data packet, and (b) if one of 
the plurality of receive buffers is unavailable, drops the data packet, notifies the second 
protocol regarding the unavailability of the plurality of receive buffers, and withholds the 
acknowledgement packet. 

12. The network set forth in claim 1 1, wherein the first protocol is an upper 
layer protocol ("ULP"). 

13. The network set forth in claim 12, wherein the upper layer protocol is an 
internet small computer systems interface ("iSCSI") protocol. 

14. The network set forth in claim 1 1, wherein the second protocol is a 
datamover protocol. 
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15. The network set forth in claim 1 1, wherein the third protocol is an iWARP 
protocol. 

16. The network set forth in claim 15, wherein the iWARP protocol is a direct 
data placement ("DDP") protocol. 

17. The network set forth in claim 11, comprising a transport protocol that 
generates a request to the third protocol to determine whether one of the plurality of 
receive buffers is available for the data packet. 

18. The network set forth in claim 1 1, wherein the data packet comprises a 
sequence field that corresponds to a reliability tracking value for the data packet. 

19. The network set forth in claim 11, wherein the acknowledgement packet 
comprises an acknowledgement field that corresponds to an identity of data received by 
the transport protocol. 

20. The network set forth in claim 11, comprising a transport protocol that 
uses a remote direct memory access network interface card ("RNIC") to receive the data 
packet and send the acknowledgement packet. 
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21. A method of managing flow control of a data transfer, the method 
comprising the acts of: receiving a data packet; determining whether at least one receive 
buffer is available for the data packet; if the at least one buffer is available, sending an 
acknowledgement packet to a node that sent the data packet; and if the at least one buffer 
is unavailable, dropping the data packet, providing a notification regarding the 
unavailability of the at least one buffer, and withholding an acknowledgement packet 
from the node that sent the data packet. 

22. The method set forth in claim 21, comprising the act of placing the data 
packet into the at least one buffer if the at least one buffer is available. 

23. The method set forth in claim 21, comprising the act of transmitting the 
data packet according to a transmission control protocol ("TCP"). 

24. The method set forth in claim 21, comprising the act of providing the 
notification regarding the unavailability of the at least one buffer via an internet small 
computer systems interface ("iSCSI") protocol. 

25. The method set forth in claim 21, comprising the act of notifying a process 
associated with the at least one buffer once the at least one buffer is determined to be 
unavailable. 
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26. An apparatus for managing flow control of a data transfer, comprising: 
means for receiving a data packet at a first protocol; means for determining whether at 
least one receive buffer is available for the data packet; means for sending an 
acknowledgement packet to a node that send the data packet if the at least one buffer is 
available; and means for dropping the data packet, notifying a second protocol regarding 
the unavailability of the at least one buffer, and preventing an acknowledgement packet 
from being sent if the at least one buffer is unavailable. 
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9 EVIDENCE APPENDIX 



None. 
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RELATED PROCEEDINGS APPENDIX 



None. 



